나는 C를 할 때 눈부시게 발전한 코드 분석도구 (소스 인싸이트라든가) 등이 있고,
소스는 레이어링 할 수 있지만 사람은 레이어링이 안 된다는 철학(?) 이 있었다.
내가 쓰는 용어로는 code locality (실제 있는 용어인지는 모름) 중심으로, 매크로 상수는 코드와 가까운 곳에 두자는 주의였다.
이게 뭔 개소리냐라고 생각할 수도 있지만 제갈호준 같은 동지도 있긴 하다. ㅋㅋ
grep의 성능은 아마도 10년전보다 1000배쯤 빨라졌다. (사실은 H/W가 빨라진 것이지만)
같은 값을 두 세 곳에서 쓰는 경우에는 반드시 매크로를 쓰는 것이 당연하지만 단 한 번만 쓰는 값을 헤더나 상수 모음 소스에 예쁘게 모아놓아야 된다는 룰은 난 좀 반대다.
소스 써핑을 할 때 두 세홉을 뛰어다니며 와따리 가따리 해야 된다고.
이건 소스 분석 도구가 좋아서 커서만 대면 작은 팝업이 열리며 알려준다 한들 짜증나는 일이다.
유지보수를 위해 헤더만 고치면 되는데 소스를 찾아서 고치는 건 위험할 뿐더러 유지보수성이 떨어지지 않나요?
네 안 떨어져요. 한 번 찾을 것을 두 세번 점프해서 찾는게 짜증나는 일이고, 코드 주변을 보고 체화할 기회를 잃는 것도 아깝다.
물론 일반론은 아니다. 그럴 때가 있다는 것이므로 소프트웨어 품질 관리론 측면에서는 좀 그렇다.
예컨데 goto를 써서 우아하게 짤 수 있는 코드는 얼마든지 있지만 goto의 활용능력은 케바케이고, 개발 역량 편차가 있는 조직에서 아 몰라 걍 다 금지! 라고 하는 것은 뭐 이해할 수 있다.
그러나 교조적으로 goto 금지라고 하면 님이 고투를 아시냐고 반발하고 싶은 것이다.
오늘도 sts로 소스 여행을 하다가 단 한 번만 쓴 변수들이 어딘가 모여있는 것을 보았다.
매크로 - 한글 주석 - 영어로 변경된 값 - 숫자 코드로 변경된 값이 있고 코드에서는 매크로를 부른다.
나 같은면 그냥 애초에 한글을 키값으로 쓰겠다. (인코딩 이슈 점검이 완벽하다는 전제하에)